Business Analyst Community & Resources | Modern Analyst

The Role of the Requirements Analyst in Driving Specialized Development Teams to Success

Seilevel — Sun, 27 Feb 2011 15:11:00 GMT

I am working on a project where Development teams are divided into specialized areas called Centers of Competence. For example, one team works on Customer data, another team on Product data and validation, another works with the Shopping Cart, another with Checkout and so on. Requirements are gathered within each of these Centers of Competence and handed off to Development for implementation.

The above approach works very well for modular functionality that is specific to a Center of Competence. For example, features specific to Customer Create are usually handled within the Customer Center of Competence and do not impact any of the other teams. But when Customer data flows from one team to another to be used further downstream for pricing, taxation, product segmentation and so on, the modular structure of requirements definition and development breaks down.

This is where the Requirements Analyst plays a crucial role in ensuring that proper functionality is developed. The key techniques we have used to ensure requirements flow across the modular functionality boundaries are as below.

1. Identify all development teams impacted by a requirement or feature request. For example, some specific Customer data may need to be captured to ensure proper pricing and taxation. These requirements will likely originate within those specific Centers of Competence, but will be developed by a different team. So, the analyst creating the requirements will clearly identify the impacted teams other than just his or her own Center of Competence.
2. Communicate clearly to impacted development teams the functionality they need to develop to support requirements in a specific Center of Competence.
3. Get estimates of time to develop, test and deploy from the other impacted teams. This is tracked as a separate task that must be completed prior to requirements being signed off for a release.
4. Conduct cross functional development and requirements meetings so that all impacted teams clearly understand the functionality that needs to be developed.
5. Define clearly the interfaces through which data and messages flow from one sub-system to another. Document any specific data requirements necessitated to support these interfaces.
6. Ensure that the test teams understand the implications for both unit testing and feature testing. There are typically two test teams to deal with. One test team works with a Center of Competence and the other is the global team that deals with the entire application.

All of the above tasks are managed, facilitated and executed by the Requirements Analyst. A good grasp of the overall application, a thorough understanding of data flow, an excellent working relationship with different teams and top notch facilitation skills are keys to success.
Good Requirements professionals managing both their individual areas and coordinating across boundaries are key to the success of the Center of Competence method of dividing and managing Development teams.

Five New Year’s Resolutions for Requirements

Seilevel — Fri, 14 Jan 2011 21:38:00 GMT

It’s that time of year, where our thoughts turn to the holidays…the holiday parties, the shopping, the lights, visiting with family! For many organizations, the end of the year tends to be quiet on the IT front, for no organization wants to risk introducing problems into their production environment at year end.

So as I look back at this year on what was accomplished, I tend to do a mini-retrospective on my year…what went well, what did not, and what can I improve? Thus looking at those items to improve, I’ve come up with a list of New Year’s Resolutions to focus on for next year:

Use the ROM – Requirements Object Model

Understand what the business problem is trying to be solved for any project that I am working on. This can be difficult to get on any project, but essentially, every project should be attempting to solve some business problem. Usually these problems are rooted in money.

Once the business problem has been identified, the business objectives can be defined. And from there, the strategy to meet those objectives can be defined.

The benefit of understanding the business problem is then you are developing a solution that will provide a return on investment. No one wants to do a project just because, there should be a purpose and it should be valuable.

Write Clear Concise Requirements

Of course I always try to write clear, concise, testable requirements. But what seems to be clear, concise and testable to me may not be in reality. So I always consider this an area of constant improvement.

How can I ensure that I am writing clear, concise, testable requirements? Reviews are always a great idea. Get another set of eyes on what you have written. I like to get a peer to review my work before sending it off to my client, and preferably, someone who is not very familiar with my project. The less they know the better. For if they can understand the requirements, and then I feel like I have done a decent job in getting them document.

But these peer reviews do not take the place of reviews by the business. They are the ultimate authority, and definitely need to be done to ensure correctness and validity.

One final word on this topic and it may sound silly to state this, but I see many mistakes made because of it: spell check does not replace proof-reading. Spell check can definitely help you ensure that the words are spelled correctly, but it cannot help you ensure that you have the right words. I’ve seen embarrassing notes go out…the words were all spelled correctly…but one wrong word could mean big trouble!

Ensure Better Transparency

Transparency means being as clear and upfront with regards to the progress and status of your project. One way to help ensure transparency is to provide status reports.

I try to send frequent and consistent status reports help provide information on how the project is progressing to those who need to know. These reports should include information such as what was accomplished that week, what was not and why, what is planned for the next week, and any risks or issues that have arisen. This information helps me keep a running record of what has happened in the project, and can help refresh memories when people have forgotten what has been done.

They do not have to take long to create, especially if you create a template, and if you are consistent with sending them out, they become part of your routine.

Do Requirements Traceability

I try to ensure that all requirements map back to the stated business objectives. This helps ensure that no business objectives have been missed, but also helps prevent scope creep.

While we all know that traceability is a good thing to do, it is laborious and tedious to do, especially outside of a requirements management tool. As requirements are written, reviewed and edited, maintaining traceability can be very difficult. I try to wait until later in the requirements definition process can save some work; however, I have to be careful about waiting too long. If I wait too long, then I may miss a chance to add missed requirements, or to prevent scope creep.

Use Models

Finally, I need to use various models to describe requirements. There is no one model that can demonstrate a set of requirements fully and completely. A combination of several models allows the requirements team and development to see the requirements from several different perspectives. It helps us gain a full understanding of what is being requested, and helps ensure that there are few misunderstandings.

While it may be easy to say “use models”, it can be a challenge to get an organization to do so. People get comfortable with their current process, and can be reluctant to change. They may resist the introduction of anything that is perceived as more work. To get around those that are resistant, I try to constantly show how the model s adds value. I remind other business analysts and product managers ultimately, the models are not for them…they are for the business to confirm their requirements, and they are for development to get a full understanding of what is desired. We are in the business to help others clearly define what they need, and to help deliver those results.

Finally, I would like to wish all of you healthy, safe and happy holiday season!

Want more on requirements and requirements models? check out our other posts.

http://requirements.seilevel.com/blog/

Is Traceability Possible Without a Requirements Tool?

Seilevel — Mon, 20 Dec 2010 05:07:00 GMT

I have spent the last year and a half working on an enterprise software solution development effort where we do not use a Requirements Management tool like Caliber or Visual Studio TFS. Our requirements are created in Word using standardized templates and distributed to Development and Test teams for consumption.

Test cases are written in Excel and tied to the requirements in the documents. In general, I would have to say that coverage is good but not complete (I know this anecdotally since there is no good way using Excel and a bunch of Word documents to know for certain). In theory, a failed test case should mean that a requirement is not satisfied and pinpoints a missed feature or requirement.

This system breaks down totally when it comes to Change Requests that are created during the course of the project. Change Requests are entered directly into a defect tracking system. Change Requests are usually supposed to have detailed requirements associated with them but in practice the quality of the supporting documentation has varied widely. So, Change Requests have little to no systematic traceability associated with them. This is not to imply that the Change Requests are poorly implemented. Just that doing any kind of systematic tracing exercise against them is near impossible.

The key problems I have found with using Excel to perform traceability are as follows.

1. Forward traceability from Business Objectives or High Level Features to specific requirements is very difficult to do and in many cases is just not practical.
2. Managing requirements as they change is very difficult to do. You could have false positives where the spreadsheet tells you there is good coverage without realizing that the underlying requirement itself has changed.
3. Managing multiple tests for a single requirement because very difficult. For example, if a single requirement has to pass 3 test cases for it to be considered fully implemented, the spreadsheet approach becomes error prone and hard to understand very quickly.
4. The spreadsheets themselves become unwieldy as multiple requirements and tests are entered. The volume of data becomes hard to manage and consume.
5. Reporting becomes a hit and miss process. It requires a lot of manual effort, is time consuming and error prone.
6. Requirements that do not start life in a requirements document (Change Requests) are seldom tracked as rigorously as standard requirements.
7. Historical analysis is very difficult to do. On projects that last several years, digging up an old Excel spreadsheet to determine if specific requirements were implemented or not a year ago can easily become a week long exercise in futility.

So what then is the answer to the question I posed at the beginning?

Excel is fine for small projects but larger enterprise grade efforts require a specialized requirements tool with good tracing features.

The odds of performing good traceability on your project are significantly improved when using a requirements management tool. There are real costs associated with unimplemented or improperly implemented requirements. A good tool gives you a better chance of catching these kinds of errors with good traceability features. So, when considering a tool to manage your requirements, do not overlook the quality of their traceability features.

For more check out our blog: http://requirements.seilevel.com/blog/

By Abadri

Challenges with User Stories

Seilevel — Mon, 22 Nov 2010 17:44:00 GMT

A Promise to have a Conversation

I’ve been writing user stories for a couple of years now, and the best way I’ve heard how to describe them is that they are a promise to have a conversation. Enough information should be written down to give the reader an idea of what the gist of the story is (and to be able to roughly estimate a story point size to it), but the details are to be driven out during discussions between the product owner and the development team at the start of the sprint.

And that concept works well when the product owner and the development team are located in the same location. As a product owner, I could attend the daily scrum meetings; I was available to the developers/testers/technical writers to answer questions as they arose.

Recently, however, I’m working on a project where the development team is not located with the product owners. In fact, development may be done in several different locations around the world. This introduces several layers of complexity that a co-located team does not have. Not only is there distance differences between the various team members, but now we also introduce time zone, language and cultural differences as well. As a result, there is a greater documentation requirement than I have had to deal with before. While the promise to have a conversation still holds, the product owner is just not as available with a geographically diverse team.

Story Size – Large vs. Small

So one of the first hurdles to jump was what the appropriate size of the user story is. I’ve had some interesting conversations with various people about this topic, and opinions do vary. Some feel that user stories should tell an end-to-end story. But that can result in very large, very complex user stories. I do see value in these user stories, and I tend to call them epic stories. I prefer to take these epic stories and break them down into much smaller user stories.

One characteristic I try to keep in mind as I write a user story is that it should be small enough to be developed during one sprint. So it is critical to understand the size of the sprints within your organization, since I’ve heard of sprints lasting anywhere from 1 to 6 weeks. It also helps to get your development organization to provide you with some rough story point sizes, so you know if your stories are of an appropriate size or not. For any story that has a point size estimate that is larger than the velocity of the team during a sprint, that story needs to be broken down into smaller stories.

What to do with Business Rules?

Another challenge is business rules. With the project that I am working on, we have finished documenting the user stories, but they only tell part of the story. They tell what the user expects to see, but not how the system gets to those results. That is the role of the business rules.

Now, if the team were co-located in the same location, this is where the promise to have a conversation would come in. During that conversation, the business rules can be vetted and discussed. However, with the geographically dispersed team, much of this needs to be written down. The story and the business rules can still be discussed, however, with cultural and language differences, having something in writing for team members to read through before the discussion and to refer back to after the discussion is a necessity.

But what is the best way to document these business rules? Some can be documented with the acceptance criteria for the user story. But sometimes there is the additional needs to get even more detailed than that, to get to the actual “if, then” statements. Where is it best to document them? I don’t have an answer to that yet, and much may depend upon the tool chosen to store the user stories.

But I am certainly interested in your experiences…how have you solved this problem?

Let us know, or check out other posts. http://requirements.seilevel.com/blog/2010/10/challenges-with-user-stories.html

Learned Processes

Seilevel — Tue, 26 Oct 2010 18:59:00 GMT

I know you are going to call me crazy, but I just have to let everyone know. Machines are controlling us. Don’t say I didn’t warn you. You don’t believe me? Okay, I’ll explain.

People come and go in organizations. Systems tend to stay much longer. Simple enough right? Here is the kicker. When that system was implemented, it was implemented to solve a problem. But it did not have all the capabilities required to solve all the problems the business had. So in order to fix the big problem, lots of little problems sprung up.

They weren’t an issue of course because the business had workarounds, usually manual ones. No biggie right? Well, maybe.

Let us say it is five years later and the original people who worked with the system are gone. The replacements were only trained on how to follow the process and not why the processes should be followed. There is the start; the machine has people doing its bidding.

Then a few years later it is decided that some systems should be replaced. So when all of the requirements analysts come in to do their thing, they document the process as is from the users and SMEs. This then gets propagated to the new systems. And thus, the old system lives on through the new system. The old bugs are now required functionality.

We must stop them! When working with old systems and processes don’t just ask what the current state of affairs is. Be sure to ask why it is done the way it is. This was happening on one of my previous projects. The inabilities of the old system were being written into requirements for the new system. Unnecessary needs for manual selections and processes were being maintained.

The project was so large and unruly that other requirements analysts would simply write down the current process and confirm it is how things work. This practice caused very complicated user interactions during the sales process and contract creation. After the fact, people realized that they should have automated more and asked the user questions about what to do less.

Because the software being implemented did not come with all this added functionality, it ended up costing the company much more money to reevaluate what was really needed, what could be covered by alternative existing features, and what would just go unimplemented.

By JHEEP

Want other software requirements posts? http://requirements.seilevel.com/blog/

Why Should We Hire You?, Part I

Seilevel — Wed, 29 Sep 2010 18:49:00 GMT

We look for the best and brightest when hiring for Requirements Analysts and Product Managers. It’s a long and difficult process with many people applying; only a fraction get through the first interview and even less are able to hang in the process as it continues. This has brought great strain to our company: as we expand we simply aren’t able to hire as very few are able to get through our arduous interview process.

Recently, we went to the University of Texas at Austin looking for interns and entry level Requirements Analysts. They asked many questions, mostly along the lines of “what does Seilevel do?”, “what would a typical day look like for me as an RA?”, “what’s the mentoring program like?”, and “what qualities do you look for in a potential new hire?”. I would like to address the last question now, to give the potential candidates out there an idea of what kind of person we look for.

Most importantly, we look for those in whom we see great potential. Can we teach and train this person? Will she be receptive? Is she able to adapt and change to the ambiguous and sometimes difficult environment? Is she smart enough to resolve tasks on her own when others are too busy to hand-hold? To get an outstanding “Yes” on all these questions is the first test to pass. When we talk to people, we want to address these questions indirectly with candidates. This means that we most likely won’t ask these questions in the form as written above, but we probe to elicit answers which give clarity to the aforementioned questions.

People are smart. Sometimes, we want to give a solution to a problem so badly that we neglect to listen to the entire problem. We look for candidates that are patient enough to listen to a whole problem before recommending a solution. As consultants, our clients look to us to solve their problems, so it’s very important that we all know how to listen. Good listening skills include maintaining good eye contact, maintaining attentive posture, and being able to summarize the problem with different words to show you understand what the issue at hand is which also uncovers underlying assumptions.

Gathering requirements includes many hours of asking probing questions to the business in order to gain a clear understanding of what the product needs to do. We want people who instinctively ask the right questions. This is a hard item to teach, so we are looking for those who have the critical thinking skills which enables them to have these types of constructive dialogues.

We want someone who works well under pressure. From school, you’re hopefully used to completing projects or papers with strict deadlines and occasionally working long hours to ensure you get that paper or project perfected. Oftentimes on a client site you will encounter strict deadlines, as each man hour over a deadline is quite costly. We’re looking for those Type-A personalities who know what it takes to get the job done well.

Many people who are Type-A and direct communicators can be considered abrasive. What’s the difference between being a direct communicator and being abrasive? We look for those who can communicate with all kinds of people without offending them, which entails being able to change how you say things to suit the recipient. In the US, if a topic is misunderstood or lost in communication, it’s the speaker’s fault, not the listener’s. We look for candidates who grasp this concept. These people can explain the same topic using different words or methods, which better suits the listener.

Prioritization is a must have. When you have a paper for English, a SWOT analysis for marketing, a business review for accounting, and a program for comp sci all due in the same month, what do you do? How do you prioritize? What comes first and why? We always have several hands pulling at our limbs, asking for time in meetings, reviews, documentation, etc. Getting it all done and ensuring client happiness is a delicate art.

My last tip for the day is to ooze confidence! Can you present in front of a room of 20 executives and the CEO? Probably not. (And it may not be a worry here, either!) However, you should be able to speak your intelligent and prepared opinion in a meeting with stakeholders. Don’t be afraid to speak up, with a caveat: as long as you know what you’re talking about. (However, you can always talk it over with another consultant if you are nervous!) As consultants, clients look towards us for answers. We need to study the issue and propose a solution, often on topics in which we may not have formal training, but our logic can trump that issue.

Many of these skills are difficult to teach someone, which is why we look for the candidate who is the right “fit”, meaning that they already possess these baseline soft skills which we can then build upon with requirements knowledge. When preparing to interview, be sure to have prepared situations that you have personally experienced which would demonstrate your capacity to fill these characteristics we look for. Look for Part II of this post next month where we will discuss critical thinking skills necessary to become part of our team.

Are you looking know someone who is? Check out our positions:

http://requirements.seilevel.com/blog/

http://www.seilevel.com/careers/

The single most important failure with requirements

Seilevel — Thu, 23 Sep 2010 00:59:00 GMT

A lot of our clients bring us in to fix their requirements issues. Based on the literature a lot of what you see about requirements is geared towards making sure that you write a requirement in the correct way – measurable, testable, traceable and atomic. Our experience with many Fortune 500 companies leads to a different issue being the most important issue, one that seems easy to solve, but is actually incredibly difficult to solve.

Ultimately software projects get chartered because an executive decided that it was worth spending the money. This should be related to a corporate strategy in some way, but usually is not. The breakdown and the ensuing issues almost always occur at this level.

The single most important failure with requirements occurs when executives charter a project without a measurable business outcome.

This sounds like an absurdly simple problem to solve, but I assure you it is not. For a variety of reasons, executives chartering software projects are adept at avoiding any sort of accountability for results. What makes the problem extraordinarily hard to solve is that it requires the leaders in the company, the CXOs, to demand that business results be identified from every program. Surprisingly this doesn’t happen very often.

The lack of clarity around measureable business objectives drives a lack of clarity to the entire rest of the project. This doesn’t mean that all projects will fail – often times project teams deliver a reasonable quality product that does generally the right things. These cases are when the issues are so completely obvious that it is virtually impossible for anyone to get it wrong. But more often people on the project invent many different reasons for why a project exists.

This single issue can result in a myriad of project problems. The issue manifests in many different ways including:

1) Projects go massively over budget because of scope creep

Scope creep is extremely easy to solve if you know what you are trying to achieve. Typically scope creep is introduced for areas that have nothing to do with the core purpose of the project. The ideas will always be good ideas, just not key to the measurable value of the project. On one project we worked on, the value was a $20M one time gain with a $20M yearly gain. The project cost was $2-3M. The stakeholder team (developers, project managers and business users) consistently wanted to add features that made the business users’ jobs more streamlined. The software would already increase their productivity, but not as much as they wanted. Because of a focus on the return (unrelated to productivity), we were able to keep the scope creep out of the release and deploy much sooner.

However on another project, the executives refuse to assign business objectives to the project and the business users keep asking for additional features that are “critical”. When we evaluated the return on the features, the return is literally almost zero and the cost is in the high 6 figures. This project is extraordinarily late and has no clear direction.

2) Projects are constantly short of resources because too many projects are being worked on

One organization we work with consistently charters too many projects. The money is there, but the resources simply are not. This means that many projects get started but then stall or are poorly deployed because key resources, including developers who know the ecosystem are simply overworked. We started on a project once that had a $4M yearly return. This was not bad, except that there was another project that had a $100M yearly return. We recommended to our stakeholders that they cancel our project and move the entire team over to the more valuable project. They chose not to and neither project has significantly deployed (6 months late). Under resourcing all projects by a little (or a lot) results in no projects being deployed well. A better strategy would be to identify the top projects by business objectives and resource them adequately. The I want it all strategy is doomed to fail.

3) Projects get canceled due to lack of interest

Projects often get chartered due to the charisma of a single stakeholder, but because there isn’t any business value they often eventually run out of steam. This actually is a better result than a project that keeps trying to deploy because canceling the project saves a lot of money. This could be avoided in the first place by proper portfolio management based on measurable business objectives.

4) Projects deliver but don’t get used by the users

This is a difficult one. We see this happen quite often and depending on the environment it may or may not be a problem. In one of the examples above, the users didn’t want to use the software because it wasn’t as easy to use as they would have liked. Yet the company could immediately get a lot of value from it. In this case it was worth it to deploy the software because the value was there and when it was explained to the users they were willing to take a usability hit to get the value. I feel bad for the users because they are the ones to suffer from these types of decisions. However I do believe that the organization is committed to successive releases that will improve usability and the cost of those is incorporated into the overall ROI . In cases where the business does not support the value the software simply does not get used. I have seen sales VPs tell the CEO that if their teams are forced to use a particular release of software that they can’t hit their very public revenue targets. This game of chicken can be avoided by making sure there is agreement at the executive level of the value of the software.

If your organization has a culture of accountability then you might already be doing these things. Our experience is that most companies have a lack of accountability for measurable business results when it comes to deploying software. As a lowly BA or IT product manager you aren’t going to be able to change the business objectives or corporate strategy, but in our experience you can make sure you understand them and even rewrite them for your team in a measurable way. This requires you to step up and choose to be held accountable. If you are able to do this and can achieve results, I assure you this is the best way to get on the career fast track.

Are you up to the challenge?

http://www.seilevel.com/

Requirements Engineering Conference Is Just Around The Corner

Seilevel — Tue, 07 Sep 2010 00:06:00 GMT

Its being held in Sydney Australia September 27th- October 1st 2010.If you are attending this conference don’t miss out on the Requirements Engineering Education and Training Workshop that is taking place September 28th.

Do you want to broaden your skills? Learn new techniques? This is the workshop for you.

This workshop will address issues related to Requirements Engineering education, both as part of a formal university degree and as ongoing skills training within the workplace. The workshop is intended to go much deeper than a surface discussion of curriculum issues and will examine specific ideas and techniques for teaching and assessing skills needed by an effective requirements engineer.

Curriculum design

Curriculum for undergraduate and graduate level RE studies
Mapping RE elements from the SWEBOK (Software Engineering Body Of Knowledge) to RE curricula
Identifying and incorporating specific RE related topics into the general curriculum and/or software engineering courses
Curriculum for industrial training programs

Techniques for teaching specific RE related skills

Creative methods for teaching stakeholder identification, requirements elicitation, negotiation and consensus building, requirements writing, and other critical RE skills
Specific tools, exercises, and assignments developed to support RE skills training

Assessment methods and practices of RE knowledge and skills

Which assessment method to use: exam, test, case study, essay, report, presentation, or something else?
Strategies for assessment of learning soft skills
What should students be able to do as a result of learning RE?
Methods of objectively measuring assessments

Effective pedagogical methods for teaching RE skills

Survey results related to topics such as the effectiveness of teaching methods, RE skills needed to be effective in industry, skill mismatches between graduating students and industry needs etc.
Studies into the effectiveness of requirements engineering educational practices
Experience reports including industrial training and university level curriculum

Do you want more information?

http://www.re10.org

http://users.cscs.wmin.ac.uk/REET10/Overview.html

Being New 101

Seilevel — Thu, 26 Aug 2010 19:04:00 GMT

Being a relatively new Requirements Analyst/ Business Analyst ( BA) and being new to the industry, I have been blessed with the opportunity to have mentors. Receiving direction from more experienced BA’s has definitely helped me find areas that I can improve on, while at the same time, finding my strengths and improving those too.

Yet there still are challenges that I face while trying to learn as much as possible. For instance, Senior Business Analysts, who are my mentors, will most likely be at client engagements for the majority of their time and it can sometimes be very difficult to find time to teach. Through my experience so far, I have learned a couple of tips that can help those aspiring and budding BA’s out there:

1. Always be on time
This cannot be reiterated enough. I will admit that I have had a slip up myself, but it is crucially important that a junior Business Analyst always be on time.

2. Ask informed questions
Never be afraid of sounding stupid. My mentors would rather me ask a “stupid question” that helps me understand the business problem than floundering about and end up making a mistake farther down the line.

3. Do not assume
Assumptions are bad. Always ask yourself what assumptions you are making when you are creating deliverables for the client. You may come up with some good questions or issues that your Senior Business Analyst didn’t catch before!

4. Use Spell Check
Spell check is your best friend when creating deliverables for clients. Not only does misspelled words make you look less credible, but it can make your organization look less professional too.

5. Take Ownership
Take ownership of the tasks that you are given. Don’t just wait to be fed information and small little projects. Instead, think of yourself being the sole proprietor of the task and think to yourself, “What can I do to make this successful?”.

6. Understanding Communication
Understanding what you are being asked to do is crucial. If you have a small amount of doubt in your mind, that is your cue to ask your Senior Business Analyst for clarification. The last thing you want to do is make the wrong assumptions and create something that the Senior Business Analyst didn’t ask for.

I hope that these little tips will help some of you aspiring and budding Business Analysts out there. I will be sure to add some more simple smart tips in my later blog posts!

http://requirements.seilevel.com/blog/

IT Black Ops

Seilevel — Sun, 22 Aug 2010 23:26:00 GMT

I’ve worked on at least one project now and heard of several others where a super-secret development team works in parallel to solve the same business problem as the “official” IT project team. A coworker of mine coined the term “IT Black Ops” to refer to these sorts of projects where the business, either out of frustration, arrogance, or ignorance, hires their own shadow development team to implement a competing solution, or an enhancement to an existing solution. I’ve never seen this go well. However, unless you are at an executive level, there is very little you can do to shut down the black ops team. In many cases, you won’t even realize the black ops team exists until the last minute when you are forced to integrate their spaghetti code solution with what the actual IT project team has built. Of course, this kind of surprise is to be expected, since the very nature of IT Black Ops is to operate stealthily, and for their business owners to neither confirm nor deny their very existence. However, once their presence is detected, a project and budgetary train wreck usually ensues.

I’ve done a little bit of thinking recently about why IT Black Ops projects are launched in the first place. It’s probably because of one or more of the following reasons:

1.Low confidence that IT will be able to build something that actually solves a business problem. Sometimes this low confidence is warranted.

2.No budget to build something the “right way” (i.e., gather requirements, manage the project, test it, and deploy it).

3.Business owner finds an extra million dollars in the budget and can finally implement his/her pet feature, even though it was initially shot down because there was no ROI for it.

Lack of understanding about why it takes so long to develop working software.
Even though the decision for the business to go undercover with their IT development will likely be disguised, there are a few ways you can help prevent them from wanting to do this in the first place:

1.Keep the business engaged throughout the development lifecycle. Giving the business partial ownership over the project by having them sign off on and review working prototypes is a great way to give them confidence in the system and make them feel as though the solution is a joint effort.

2.Sell them on the value of process. The ROI for good processes is difficult to calculate; however, turning a team of developers loose to write code with no requirements or process discipline is about as successful as hiring a room full of 1000 monkeys to develop your solution. Giving the business ownership of the process will help.

3.Each project should have a clear ROI. This sounds obvious, but too many projects have a vision statement akin to “you know it would be really cool if…” People also become emotionally invested in certain solutions, without taking the step back and evaluating how well the solution solves a business problem. Just watch out for pencil-whipped and contrived ROIs. Be suspicious of any feature which does not tie back to a quantifiable business objective.

4.Use comparable projects to set expectations. People who do not work in software development often find it difficult to understand how expensive and time-consuming software development can be. This can sometimes lead to the attitude of “This is simple–I can do it faster and cheaper myself”. In order to head this off, it helps to show the budget, resources, and time to execute for similar projects. It is natural to ask the question “Why is it so expensive/time-consuming/so resource-intensive?” You can use the lessons learned on other projects to help answer this question.
It never really helps to mention that the black ops team will always fail, that someone will get fired if the black ops project continues, or that it will end up being more expensive in the long run–even though these statements are almost always true. Once the black ops team is hired, you’ve already lost, so do what you can to prevent IT Black Ops projects from being launched in the first place

This blog post will self-destruct in 500 views.

By Jhulgan

Want more? Check out our other posts here.

Lessons for a Good Hair Cut

Seilevel — Sun, 22 Aug 2010 23:22:00 GMT

Last year, I wrote about my Lessons from a Bad Haircut. I’m please to say I finally have a lesson from a good haircut.

How did I finally get a good haircut?

It was what the stylist did after I explained what I wanted. She drew a quick sketch. It took about 15 seconds. And, with that sketch, I was able to say “No, that’s not what I want.” 60 seconds more of discussing what I wanted while pointing at the sketch, and she’d refined the sketch until both of us were confident that we were talking about the same thing. The sketch was very crude and would never be confused with a work of art. But, that wasn’t the purpose. The purpose was to convey an idea. And it did. And, I got a good haircut.

So, what does this have to do with requirements?

Most people relate to pictures much more easily than to words. “Pictures” are all of the diagrams included in the RML®, such as process flows, wire frames, BDDs, etc.

One of the major things to remember about creating these diagrams is that they don’t have to be perfect to be useful. They simply have to be sufficient to convey the idea. And, once a model of the idea is out there, the discussion becomes very productive. If you can project the diagram or sketch it on a white board, people will point at it and discuss—what’s right? How do we make fix what isn’t? At the end the discussion, with an updated diagram, you’re ready to move forward with all parties confident they are headed down the same path.

When working with a client who wants me to skip the model and go straight to the words, I’ve found they react well to the statement “If we’re not in agreement about the model, we won’t get the words right.” They get it: it’s a matter of being more efficient and synching up our understanding as rapidly as possible, rather than wasting time on misunderstanding.

If I revert to my hair style of ten years ago–all one length and all I need is a trim–I can skip the sketch or picture. Otherwise, a picture or sketch will be a prerequisite to any haircut I get. I similarly recommend that requirements models be a prerequisite to any requirements you write.

Want to read other blogs? Check us out here.

What do you do when the client isn’t focused on the business outcome?

Seilevel — Tue, 17 Aug 2010 18:56:00 GMT

One of the values that we bring is that we can help our clients to decide what scope to cut by providing them with a framework that links quantifiable business objectives to specific features. We create an objective chain to do this and it helps to spotlight features that don’t feed into the core business purpose. Typically our stakeholders are able to cut a minimum of 10% of features and as much as 90% while achieving their objectives.

What we are finding though is that it is sometimes a challenge because the features that are good for the company are not necessarily good at making the lives of the people using the software easier or better.

We have recently run into a case (I’m changing the dollar values and the features for confidentiality reasons) where the business side of our client had identified $50 million in potential savings each year in an area of the business related to giving discounts. The issue was that the discounts were being calculated manually and there was the serious possibility that customers were claiming millions in discounts twice. The discounting system and rules are very complex with overlapping effectivity dates, products, regions and discount rules.

The business was confident in the $50 million number based on industry studies that showed that typical companies were giving away 5% more than they needed to in improperly calculated discounts. However, no one could identify specific types of problems that might be leading to double payment. We did a little research and analysis and decided that the biggest risk area was multiple overlapping discounts and so made that the focus.

There were several issues that came up. The most critical was that the users of the system and the business team while acknowledging the problem with overlapping discount agreements, were basing their decisions on the efficiency of the team. The calculating team is an offshore team with 8 people focused on this portion of the process. The company had done a study to show that full automation could reduce headcount from 8 to 2 people.

However our view was that the savings associatied with reducing headcount from 8 to 2 people was so minimal that it wasn’t worth the effort in the beginning when we were faced with such a large amount in overpayments. Instead we felt that focusing on the features that would automate detection of overlapping agreements were absolutely critical. Deploying those features as quickly as possible was paramount because of the massive revenue leak associated with the problem. Leaving a majority of the process manual would actually be ok if the system had the ability to determine when multiple discounts were being applied to the same purchase and thus eliminate the lost dollars.

It turns out that the business simply didn’t want to fund the project unless their work was decreased, even though in the overall scheme the cost savings was minimal. In the end they approved funding for a first phase that has full automation but does not actually focus on detection of the business case driving error conditions. The detection of the error conditions will come in later phases, so ultimately they will get the business value.

We see this often where at the level of individual features, the subject matter experts have mandatory features that will make their life easier but don’t necessarily contribute to the business case for the project. These features create a death by a thousand cuts situation. Our methodology can identify the “unnecessary” features, but ultimately it is up to the client to decide if the business case is really the highest priority.

Want to see other blog posts? Check us out here: http://requirements.seilevel.com/blog/

It’s So Hard to Say Goodbye: Tips for Getting Closure on Your Project

Seilevel — Thu, 12 Aug 2010 18:50:00 GMT

Sometimes projects are like villains in horror movies: they just won’t die. Even when you’ve doused them in gasoline, set them on fire, then dumped them in a river, they just keep coming back. A project’s extension beyond its natural or expected life is not good for the project as a whole (even though it might help keep you busy). Projects are expensive and each unnecessary day spent on a project is hundreds (or sometimes thousands) of dollars that could be allocated elsewhere. Here are some tips than can help you keep the project moving towards a harmonious end for both the business and IT teams:

1. Feature Alignment: Make sure that the business understands all of the features that will be delivered as part of the project. The BRD or other requirements documentation should spell out very clearly the features that will be delivered as well as those that will not. This sounds very obvious, but it is important and sometimes neglected at the beginning of projects.

2. Fix my Defects! Here’s a dirty secret about the software industry: all software has defects! Not surprised? Well, unfortunately and often understandably, resources will be asked to stay on a project until “all defects are fixed”. If you’ve agreed to such a request, get ready to be on the project for a long, long time. A better plan is to have agreement on the level of severity of which defects will be fixed before project exit–for example, all “Critical” or “Blocker” defects. There may be disagreement as to what counts as a “Critical” defect, but much ink has been spilled on this subject already.

3. Confidence is Key Regardless of how many defects are fixed, how well the project is planned, and how proud you are of your team, your users will not be prepared to see their safety net pulled from under them if they don’t feel comfortable using the system you’ve built. One way to build confidence is by building and measuring user adoption . But sometimes, it just takes a lot of hand-holding and training on how to use the system, and an explanation of the business value.

4. Focus on Business Value No system is perfect, but every system should be built to achieve a business goal. When everyone is “in the weeds” reacting and focusing on discrete, individual tasks, it’s easy to lose sight of the big picture. It’s a good idea from time to time to review the project business objectives especially when there is disagreement over which defects need to be fixed before project exit.

Do you have other tips? Let us know!

Top 10 User Acceptance Testing Preparation Tips

Seilevel — Thu, 05 Aug 2010 18:15:00 GMT

If you are a Product Manager or Business Analyst in charge of managing users through User Acceptance Testing (UAT), here are the top 10 things to do to prepare:

Formal scripts – prepare formal scripts for the business users to run. If you can re-use any of QA’s scripts, all the better. At a minimum, use your use cases to build test scripts. As an added bonus, these scripts will serve as training to the business users on how to use the system after deployment. We suggest you have scripts for testing both functionally and migrated data.
Informal scripts – prepare informal, unstructured scripts for the business users to run as well. I strongly encourage you to do these in addition to formal scripts, in that these are the ones that will pull out defects about how the system isn’t intuitive to use. In addition, they may think to test things you didn’t formally script. As an example, this type of script might simply say “Login to the system and take a training course.” And you are hoping it’s intuitive to the user to figure out how to do that on their own.
Use a tool – we strongly encourage you to put your scripts in a tool and teach the business users how to use that tool. For example, Quality Center is a tool that works well for this.
Master data – create master data that can be used for testing by the business users. This includes logins and passwords and any data they must look at and/or consume in the tool. A great starting place to determine what data you need is to look at your Business Data Diagrams, and then of course look at your scripts. For example, if you have a training system, upload sample training courses for them to take during UAT. You should also organize this master data into a format such as a spreadsheet by test case, so they can quickly reference what data they should use in each script.
UAT Kick-off deck – Create a slide deck to kick the UAT window off with. This kick-off should include the scope of testing, a reminder about the value of the system, a reminder that it is a testing phase and they will find defects in the system, and instructions on how to perform UAT. You need to teach them about using the tools, how to login, and even where to go to access the system.
UAT User Manual – Create a manual for the users to quickly reference to while they execute the UAT scripts. You can hopefully reuse some or all of your kick-off slides. You definitely must include where to access the system (URLs), logins, and where to find master data.
Pre-run scripts – Ideally you should pre-run the scripts before the business users try to execute them. You are familiar with the system, so your eyes on the scripts will be looking for things that are not obvious or incorrect steps. This will help ensure a much more smoothly run UAT.
Teach them how to write a good defect – If you want to avoid a lot of manual labor yourself, teach the business users how to enter their own defects into a defect tracking system (and yes, I’m assuming you have one!). You need to teach them what information to include (logins, urls, steps to recreate) and how to set severity and priority values if appropriate.
Coordinate build schedule with dev – Make sure your dev team is onboard with your UAT testing schedule so that they don’t do a build while users are trying to test. And more importantly, if they do a build overnight, that they don’t take the system down with a broken build! In general you need to coordinate with your entire IT team, I just call this one out as they have an immediate way to cripple testing by accident.
Work with a business owner so they truly own acceptance – All of that said, you need to make sure there is someone in the business who owns the UAT process. You are simply here to facilitate it going well and do a lot of the prep work for them. But truly, they must be the ones who own acceptance of the system or they will never actually adapt it for use. So every step of the way as you go through your prep tasks, be sure you are getting the business UAT owner’s buy-in!

And a bonus #11: Have fun with it! This is when you get to see your system come to life with the people who will be use it. If you have fun, they’ll be more likely to have fun and actually enjoy this!!If you are a Product Manager or Business Analyst in charge of managing users through User Acceptance Testing (UAT), here are the top 10 things to do to prepare:

Formal scripts – prepare formal scripts for the business users to run. If you can re-use any of QA’s scripts, all the better. At a minimum, use your use cases to build test scripts. As an added bonus, these scripts will serve as training to the business users on how to use the system after deployment. We suggest you have scripts for testing both functionally and migrated data.
Informal scripts – prepare informal, unstructured scripts for the business users to run as well. I strongly encourage you to do these in addition to formal scripts, in that these are the ones that will pull out defects about how the system isn’t intuitive to use. In addition, they may think to test things you didn’t formally script. As an example, this type of script might simply say “Login to the system and take a training course.” And you are hoping it’s intuitive to the user to figure out how to do that on their own.
Use a tool – we strongly encourage you to put your scripts in a tool and teach the business users how to use that tool. For example, Quality Center is a tool that works well for this.
Master data – create master data that can be used for testing by the business users. This includes logins and passwords and any data they must look at and/or consume in the tool. A great starting place to determine what data you need is to look at your Business Data Diagrams, and then of course look at your scripts. For example, if you have a training system, upload sample training courses for them to take during UAT. You should also organize this master data into a format such as a spreadsheet by test case, so they can quickly reference what data they should use in each script.
UAT Kick-off deck – Create a slide deck to kick the UAT window off with. This kick-off should include the scope of testing, a reminder about the value of the system, a reminder that it is a testing phase and they will find defects in the system, and instructions on how to perform UAT. You need to teach them about using the tools, how to login, and even where to go to access the system.
UAT User Manual – Create a manual for the users to quickly reference to while they execute the UAT scripts. You can hopefully reuse some or all of your kick-off slides. You definitely must include where to access the system (URLs), logins, and where to find master data.
Pre-run scripts – Ideally you should pre-run the scripts before the business users try to execute them. You are familiar with the system, so your eyes on the scripts will be looking for things that are not obvious or incorrect steps. This will help ensure a much more smoothly run UAT.
Teach them how to write a good defect – If you want to avoid a lot of manual labor yourself, teach the business users how to enter their own defects into a defect tracking system (and yes, I’m assuming you have one!). You need to teach them what information to include (logins, urls, steps to recreate) and how to set severity and priority values if appropriate.
Coordinate build schedule with dev – Make sure your dev team is onboard with your UAT testing schedule so that they don’t do a build while users are trying to test. And more importantly, if they do a build overnight, that they don’t take the system down with a broken build! In general you need to coordinate with your entire IT team, I just call this one out as they have an immediate way to cripple testing by accident.
Work with a business owner so they truly own acceptance – All of that said, you need to make sure there is someone in the business who owns the UAT process. You are simply here to facilitate it going well and do a lot of the prep work for them. But truly, they must be the ones who own acceptance of the system or they will never actually adapt it for use. So every step of the way as you go through your prep tasks, be sure you are getting the business UAT owner’s buy-in!

Do you have comments? Want to check out our other blogs? Check us out here.

RML® Model 4 – Data Dictionary

Seilevel — Thu, 05 Aug 2010 18:09:00 GMT

When creating a data dictionary, it is critical not to design with it. You should not be attempting to create a database nor should you be showing the relationships of data. This will be a detailed description of the data involved in your project. It will also be one of the largest morale draining approval processes you can have for a document. They will be very time consuming an have the potential to have a good deal of churn over the data items they hold.

One of my former projects demanded a great amount of detail be gathered from the existing systems to be implemented in a new outside system. Unfortunately there were several large problems with the way Data Dictionaries were used. One of the two largest problems was that there were upwards of twenty different data dictionaries that were being worked on independently by different functional areas of the project. The other huge issue was that only fields that were visible to the business were being captured.

Having multiple data dictionaries for the same project causes many issues and can lead to delayed development and incomplete requirements. If there are 10 different Data Dictionaries that all call for a field identified as ‘Credit’, how does one figure out if they are all the same field? If they are the same field, which of the different entries has the correct business rules and attributes? If they are not the same field, how will the names be reconciled? If they are different, which one was being referred to in other documentation and models? And what about the one field labeled ‘CustCred’. Was that the same? Were all the business SME’s aware that ‘CustCred’ was included in only one of the data dictionaries?

Failure to engage the Business and IT in creating a Data Dictionary can lead to a plethora of data not being identified and documented. Unfortunately when only the business is involved in creating a Data Dictionary, it tends to only get populated with fields that can be seen, either on the screen or in reports. IT will be able to provide input around these fields. What is not being seen is that when you enter your account number and password, the system is keeping a log of your user id, the date the login attempt occurred, the outcome, and your IP address. Without IT there, you could have just lost 4 of the 6 fields required to login. Additionally, if you have to go back a separate time with the IT group, you will have to bring the Business in even more to make sure that the business name you have recorded is the same as the field IT identified. Just because it says customer name on the screen doesn’t eliminate the possibility that it is actually ‘cust_legal_name’ in the database.

I have found the following fields to be a robust baseline for any data dictionary I create:

-ID – unique ID to keep track of the data fields

-Category – Organizational field that can help group data

-Business Name – Official or most widely recognized name for the data

-Aliases – Abbreviations or alternative names the data could go by

-Data Field – Field used in the database (mostly used on gap projects)

-Description – Short description of the field for context

-Formula – If the field is calculated, include the formula used to come up with the value here

-Business Rules – Any actions or restrictions that must apply to this data

-Data Type – generic data type such as ‘alpha’, ‘numeric’, ‘alphanumeric’, ‘currency’, ‘date’, or ‘time’

- Length – Maximum allowed length of the field

-Owner – Individual or group who currently owns an action item for the field

-Status – Draft/Reviewed/Approved/Removed/etc.

- Notes – Misc notes to be taken about the field such as links or individual’s comments

-Issues – List of unresolved issues or action items with the field

Keep in mind that the Data Dictionary is best in situations where you have an undefined data model or in situation where you are involving new systems. This data model will become less useful when dealing with a smaller or more defined/understood data set or if you are short on time.

Unfortunately this model is also not a visual model. This means that it will be much harder for people consuming it to quickly learn the data being presented and it will also be difficult to quickly interpret the data being presented.

You are almost always going to find this document living as an excel spreadsheet. If you plan on having multiple large groups working on the same project, you should consider having a collaboration tool for this document such as Google Docs or SharePoint lists. Multiple lists being worked on separately can cause massive headaches and prove to be massive time sink when trying to correct and compile. As a best practice, one should never delete data either, but rather mark it as removed or do a strikethrough formatting. This will allow you to know that it was documented but deemed unnecessary instead of forgetting about that one remote field and researching it again to find out you cut it already.

Pro Tip for excel users:

Holding down Alt and pressing Enter (Alt + Enter) while typing in a cell will allow you to return

to the next line within the cell as if it were a word document. This will make it easier to format notes or add multiple aliases/data fields to a single row.

Fun tip- for those who have sympathy for making others do a data dictionary review: bring koosh balls, stress relievers or fun packs of play-doh for your attendees to keep their brains semi-active during the reviews.

by jheep

Want more models? check us out here.

Building Credibility With Your Team

Seilevel — Wed, 28 Jul 2010 22:07:00 GMT

As consultants and product managers, it is important that we quickly build and maintain credibility with our team so that we can work productively and effectively. If you are unable to join the team dynamics, the work that we provide will be met with apathy or even outright hostility. I’ve learned a few tips to help establish credibility quickly.

Maintain your visibility – Initially, it is important to get plugged into as many face-to-face meetings and conversations as possible. By being face-to-face it gives you the availability to learn more about the project right away, gives you context, and you will quickly meet many of the people who might influence your efforts. Your team can see you demonstrating your expertise and learning about the challenges of the project. They will see you as a member of the group. If you are not able to join many meetings, just being onsite and visible will help establish your presence.

Learn about your customer and your team - Knowing the business issues and pain points of the project team will help establish your credibility. Research the business and the challenges before meeting with your team. Usually, you will have a point of contact within the organization who can share the current challenges, and possibly some of the team dynamics. It’s also important to keep an open mind when learning about a new group. Everyone has a perspective and until you can gather your own impressions, take what’s shared with you with a grain of salt.

Be Personable – It is critical to try to establish a personal relationship beyond the necessary professional one. I’ve found that if a new team member can connect with me on a personal level; it goes a long way towards smoothing out the edges professionally. Try to ask your team members about appropriate things that matter to them, like kids, interests or holiday plans. If you do ask, be sure to remember what they told you and be genuinely interested. If you do ask about a team member’s personal interests – Don’t forget the answers. Even if you have to jot them down on a notepad to remember later. It’s critical that you not ask the same personal question twice. People may give you a pass if you repeatedly ask the same question about work related topics, but if they care enough to give you an answer about something personal, you should care enough to remember it.

Be a good communicator and listener – The ability to communicate effectively and sincerely will always enhance your ability to establish credibility. It’s important to be engaging, and build professional relationships. Effective communication can quickly build a personal rapport between you and the other team members.

Never let ‘em see you sweat-

This is hard to do in practice but important. If a person is going to have faith or confidence in your ability to get the job done, then you should have faith in yourself. Issues and problems will come up from time to time, but having grace under pressure allows people to feel comfortable that you are the part of the solution and not part of the problem.

Do you have tips on how to build credibility with your team? Do you want to check out other blogs?

You can check us out here.

By Landerson

How many Business Analysts do I need on my project?

Seilevel — Tue, 27 Jul 2010 15:29:00 GMT

At the beginning of almost every project (and even sometimes midway through them) we are asked to create a requirements plan and estimate the time required on tasks and the number of BAs necessary to execute it. In a later post I’ll talk about the actual plan items, but we do have a rule of thumb for how many BAs you need on a project.

We have a standard metric we use: we suggest 1 BA can support 4 to 8 developers. Typically I suggest 1 BA to support 4 to 6 developers though, as 8 is a stretch on many projects. Of course this number is highly dependent on the context of your project, so treat it as a rule of thumb only.

As an example, right now we have 7 developers working on rebuilding existing functionality from an existing site and it’s required just over 1 BA to work on the requirements for it. And even at that, the BA is pretty stretched to get them done as fast as the dev team needs them. And in another part of the project, we have 1.5 BAs supporting about 4 developers who are doing defect testing – but they are also very intensely focused on UAT activities.

ByJBeatty

How many BA's do you need on your project? Do you have comments?

http://requirements.seilevel.com/blog/2010/07/how-many-business-analysts-do-i-need-on-my-project.html

How do you determine if you have a business rule?

Seilevel — Fri, 23 Jul 2010 14:09:00 GMT

On a recent client’s project, we were asked to help in the effort of creating a system to automate much of the current manual processes. In order to capture the requirements this also meant that we were documenting the business rules that were currently being used. When I started the project, I did not have a complete understanding of how a business rule was different than a requirement statement. I found that I was constantly getting mired in my confusion between the two.

From my research I did find one Wikipedia article to be particularly helpful, but I simplified that advice even further. From my reading and experiences, I created the following four guidelines to help me determine if a statement was a business rule that would need to be represented within the new system and should described within my functional requirement statements.

1: A business rule is about the how to run the business and not about a system, or set of systems. If you removed all the systems and system platforms, the rule would still important to the business operations. Business rules are about people doing business activities, to achieve business goals not interacting with systems. A very simple rule that is used every day is “No shoes, no shirt, no service” a person can read this rule, and know what actions they are to perform. A functional requirement would be to support the “No shoes, no shirt, no service” rule within the system.

2: Does the rule provide enough information for a business person to make a decision, or a series of decisions? If a business person uses the rule to make a decision, then it’s a business rule. The rule exists in order to operate the business. A business person could easily read the rule and understand how they are to conduct business.

3: Business rules are owned by the business. A business person must be able to change, or modify rules as they identify changes. For example, a rule may be that “Only people between the ages of 25-35 may open a customer account”. A system requirement could be written to support that age constraint. The rule however, is owned by the business and could be changed at any time based on business objectives.

4: A business rule must place some type of constraint or requirement on the way that business is conducted. For example, “Only customers with an approved line of credit of $1,000 or more may place orders within the corporate product catalog”. This rule shows how customers are constrained and prevented from certain operation, or activities. A system requirement might be necessary to support multiple rules which constrain customer activities. The business rules define the constraints.

by LAnderson

Do you have feedback on how to determine a business rule?

Work Harder, Not Smarter

Seilevel — Thu, 22 Jul 2010 16:13:00 GMT

I am all for great tools and processes that increase efficiency of work, facilitate better accuracy, allow for repeatable results, so on and so forth. But sometimes they simply do not fit. Yes, I just said better is not always good. Why? Spending time trying to improve tools or processes on short turnaround projects or tasks is usually detrimental to the goals at hand.

I have known several individuals who focus more on the tool than the deliverable. In one of those instances they were almost obsessed with the tool, an excel spreadsheet in this case. Over the 3 week project I don’t believe they actually contributed to the content of the list. What was supposed to be a listing of the gaps by area between two processes became a quest to make it such that the excel sheet could be filtered and manipulated such that niche sets of data would align or show patterns. This functionality did not contribute to the project at hand, combine the two processes.

Despite trying to get him to complete the template and move on, he continued to tweak the tool. In the end I resorted to taking one of the iterations of the spreadsheet and working only from that copy, ignoring revisions he had made. By the end of the project I believe I was able to capture all of the gaps and was able to hold the necessary meeting to finalize what must, could and shouldn’t be implemented. This was despite the fact that my list did not have all of the ‘functionality’ of the still evolving spreadsheet.

It is not easy to try to influence people to not get sucked into these constant improvements. Also be careful not to let yourself or your colleagues start to use it as a procrastination tool. “Oh, I’ll start documenting that database with hundreds of fields right after I get this spreadsheet just right.” This is also not good. Big tasks such as data dictionaries are always a pain to get started, but the more you tweak that layout, the more you delay the celebration of no longer having to go through all those line items.

Simply put, what must be done should not be hampered by the lack of sophisticated or niche tools. When there isn’t a deadline breathing down your neck, feel free to start embracing those new best practices or updating the templates.

By JHeep at Seilevel Inc

Do you have comments? Do you want to read more?

Check us out here: http://requirements.seilevel.com/blog/

Is Your Product Knowldege an Asset or Liability?

Seilevel — Wed, 14 Jul 2010 16:19:00 GMT

There was recently an interesting post by John Mansour on the Austin PMM Forum (registration required) discussing whether Product Knowledge was an Asset or Liability to product managers.

The author makes several claims about how product knowledge is a liability:

“In a nutshell, the more product knowledge you have, the less product management you’re doing because your product knowledge gets you sucked in to a plethora of non product management issues.”

“Furthermore, too much product knowledge leads to micro management – the kiss of death for anyone in a leadership role.”

“Detailed product knowledge = liability because you can’t see the forest from the weeds.”

“Detailed product knowledge = liability because it forces you more into ‘how’ features should work instead of ‘what’s needed and why’ from a business perspective.”

“The more you know about your product the more difficult it is to position its true value. “

I have to disagree with Mr Mansour that these are true liabilities, in the sense that the absence of product knowledge doesn’t truly mitigate the liabilities. Good product management is fundamentally about good product management.

It’s your job as a good product manager to avoid running down the ratholes that you could run down as a result of your product knowledge.

Post by MTalbot at Seilevel Inc

check out other blogs here.

Creating Accurate Time Estimates

Seilevel — Fri, 25 Jun 2010 19:45:00 GMT

By Landerson

I recently joined a new project where I will be working as the person responsible for the developing and creating the requirements and documentation on a major development effort. As the person on the hook for a significant portion of work, I need to provide accurate time estimates for my portions of the project. I was concerned about providing accurate time estimates on a new project in a new environment. I am also very aware that deadlines are important and know that if I am unable to accurately estimate my deliveries, I will quickly lose credibility with the rest of the team. Underestimating my deadlines might also put other team members relying on my work at risk of missing their deadlines.

My concerns had me thinking that perhaps others might be in a similar situation. After a bit of research and analysis of my own process I compiled the following list of questions and suggestions to help when making time estimates.

How accurate do your time estimates need to be?
If an estimate needs to be very accurate, it is usually a good idea to take a longer period of time to consider and analyze the answer. It is not unreasonable to ask someone who is looking for a timeline for some “think time” in order to provide an accurate answer. However, when not immediately responding, it is a good idea to communicate a reasonable target for when you will have the estimates finished, even if it’s only 15 minutes of extra think time.
How well do you fully understand the project/tasks that you are being asked to estimate?
If a problem is complex, or if you do not completely understand all of the tasks you need to finish, it will be difficult to make accurate time estimates. Getting as much clarification as you can is necessary. Discussing the details of what you have been asked to accomplish with the person making the request might also provide them insight into the complexity of the request and your work process.
How long has a task of this type taken to accomplish in the past?
It is a good idea to maintain a personal log of tasks and an ongoing list of recorded time spent performing a task. I simply use an excel spreadsheet to record tasks I have finished on my projects and update it when I have a few moments at the end of the day or week. Having a realistic idea of the amount of time I spend on my tasks helps me to accurately predict future projects/tasks.
Are there any assumptions, conditions or constraints which might affect your time estimate?
It is impossible to predict in advance every detail of a project with certainty. It will be important to note your assumptions and constraints when you provide your time estimates to communicate your issues clearly. These could all be considered risks to the accuracy of your time estimate and should continue to be monitored as you begin the tasks/project.
Do you need to add any wiggle room?
You should consider adding contingency time if there is a lot of uncertainty about the tasks or many risks associated with your estimate. By increasing time to the estimate appropriately because a project is new and unfamiliar as a way to prevent underestimating your efforts.
Are there any other elements to the project/tasks that should be included in your time estimate?
One area I consistently forget when creating estimates is the amount of extra time I have to spend doing administrative tasks like organizing meetings, sending emails, or organizing documents. At times, these types of activities are not always predictable, but understanding how much of your work might be effected by other project duties is important. There is a small amount of extra administrative work in most tasks, and adding that into your work estimate will help your estimating efforts.

When I employ these methods they have lead me to more accurate time predictions that have also greatly reduced my anxiety over creating self imposed deadlines that are unrealistic. As I also have an intrinsic desire to please the person asking for my time, using some standard processes in producing my time estimates has lead me to win/win situations for both my project and myself.

You can check out our other blog posts here

“So, what do you do for a living?”: A BA/Product Manager’s guide to surviving cocktail parties

Seilevel — Thu, 10 Jun 2010 13:52:00 GMT

By Jhulgan

I used to dread hearing the question, “So what do you do for a living?” This was often usually asked by a family member or other acquaintances not familiar with the software development lifecycle, IT, or business processes in general. For business analysts, product managers, and other software requirements types, it’s difficult to give an answer without being convoluted or sounding like Tom Smykowski:

This great post expresses a similar insight beautifully, but many of us struggle with good, one-sentence responses to what it is we do everyday in simple English. I thought I would plagiarize some ideas that I’ve heard from colleagues over the years and compile them here:

“We help businesses figure out what software they need to build to solve business problems.” This is a personal favorite of mine that I stole from Marc (who posts under mtalbot on this here blog). It’s especially relevant to IT consultants/contractors. Just about everyone knows what software is, and a lot of people understand that just about every business runs on some sort of software to solve business problems.
“We help communicate the business needs of a system in a language software developers understand.” A variation of this is, “We translate from business to geek”, although I am less fond of the second version because it veers into Smykowski land.
“We make sure the right software is being developed at the right time, for the right people.” The emphasis here is on the right software. This response is nice because it allows you to segue adeptly into a discussion about business objectives.
“We help the business get the most value out of their development dollar.” This response stresses the fact that you are not just a scribe or secretary writing things down, formatting them, and delivering them to the development staff. You are helping make the tough decisions on which features to cut and which bugs to fix, and quantifying those decisions in terms of dollars and cents.
“We work with the business to find the appropriate scope of a software development project and ensure that what is built is what the business expects.” Whenever I am asked the dreaded WDYDFAL question, this is what almost immediately comes to mind. Sometimes I fill in the details of working with pictures to help model current business processes (and desired business processes).

So how about all of our readers? What answers have you come up with? Do you dodge this question altogether, or do you sound like a fumbling Smykowski? Hopefully we can all help each other find good answers to this question. After all, you never know when you’ll be in a meeting with “The Bobs” and the pressure will be on!

You can check out our other blog posts here